home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7952 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB
  1. Path: news.crystalball.com!news
  2. From: Larry Weiss <lfw@oc.com>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: #include --> Question
  5. Date: Thu, 29 Feb 1996 14:15:12 -0600
  6. Organization: crystalball.com
  7. Message-ID: <31360950.4883@oc.com>
  8. References: <4gvp2c$sdr$1@mhafc.production.compuserve.com> <4h1d2l$4n3@pyrrhus-f.hrz.tu-chemnitz.de> <4h2si8$1bf@solutions.solon.com> <31359A05.4014@iadfw.net> <4h4spq$c68@solutions.solon.com>
  9. NNTP-Posting-Host: external.oc.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (Win16; I)
  14. CC: lfw@oc.com
  15.  
  16. Peter Seebach wrote:
  17.  > 
  18.  > >Peter Seebach wrote:
  19.  >
  20.  >    >> The character '\' introduces undefined behavior in a header file name.
  21.  > 
  22.  >   >Peter, are you sure about this?   Can you cite a clause of the Standard?
  23.  >   >I'm looking at Clause 6.8.2 and 6.1.7.  The only characters that cannot be
  24.  >   >used in a #include "name" header name according to those sections are
  25.  >   >newline and doublequote.
  26.   
  27.  > (Because all of the relevant quoting characters are being discussed, I will
  28.  > use q for quotes.)
  29.  > Ahh, but you must also read the paragraph below that (also 6.1.7), which
  30.  > states that if the characters q'q, q\q, or q/*q occur between the q"q
  31.  > delimiters, the behavior is undefined.  (Between q<q and q>q, q"q also
  32.  > introduces undefined behavior.)
  33.  > There's a footnote (25) attached to this - "Thus, sequences of characters that
  34.  > resemble esqape sequences cause undefined behavior."
  35.  > 
  36.  >    >Of course, all interpretation of the characters used to signify a
  37.  >    > #include "name" are implementation defined.
  38.  > 
  39.  > Yes.
  40.  > 
  41.  
  42.  
  43. OK.  I see it now.    So, it would be permissible (Clause 3.16) for an 
  44. implementation to document exactly what the consequence of using '\'
  45. in a #include "name" scenario would be.....and because it's up to the
  46. implementation to document what even the not undefined behavior
  47. causing constructions using #include "name" really mean, then there's
  48. really not much difference to those implementations that do allow
  49. '\' to have meaning in #include "name" directives?
  50.  
  51. There are of course, portability concerns, but it seems that not much is
  52. guaranteed anyway regarding portability of #include "name" directives
  53. by the Standard.
  54.